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In the April issue last year we published an article that showed how to 
program the serial port correctly under Windows. The methods 
described in that article appeared to be a bit too complex for many 
people. For this reason we wrote our own DLL, which can be used to 
simplify the programming of the serial port. This DLL will be described 


in this article. 


The serial port is still used by many electron- 
ics hobbyists to connect their computer to the 
outside world. This makes perfect sense, 
since such an interface is found on every 
standard PC and it also provides a few input 
and output signals as well as the serial com- 
munication channel. The USB port has these 
capabilities as well, but this requires some 
extra circuitry and many hobbyists would 
prefer to avoid that. In this context it’s better 
to keep quiet about ISA and PCI cards too. 
The serial port still remains the favourite solu- 
tion when a simple connection is required 
between a PC and some electronics. 


Programming 


The way in which serial ports are pro- 
grammed has changed tremendously over the 
years. Under DOS they could easily be con- 
trolled directly, without affecting the operating 
system. Under Windows this changed com- 
pletely. Although the earlier versions of Win- 
dows still permitted the direct access of the 
hardware, programming the serial port 
became much more complex. The more recent 
versions completely refuse to let programs 
access the hardware directly. Windows now 
takes responsibility for this and likes to stay 
in control. It’s only in this way that Windows 
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can keep control of all hardware 
access. 

The only (proper) method for con- 
trolling the serial port under Win- 
dows is via the Windows API. A 
number of functions for the serial 
port has been included in the API 
(these were described in the previ- 
ously mentioned April 2002 article). 
There is still a lot of work involved to 
control a serial port using these func- 
tions. It would be much easier if the 
basic routines required for control- 
ling the serial port were provided by 
a DLL, so the programmer has no 
need to concern himself with the 
communications between the pro- 
gram and Windows. 


Serial.DLL 


Many readers will probably appreci- 
ate that we have written a DLL that 
can be used to control a serial port in 
a simple manner. Apart from trans- 
mitting and receiving characters, it 
is also possible to request the state 
of the input pins and set the state of 
the outputs. 

An extra feature included in the 


Table I. 


The complete list of functions 
and routines in the DLL. 


OpenCOM 
CloseCOM 
IsPortOpen 
GetPortNr 
COMPortExists 
SendCharCOM 
ReadCharCOM 
SetTxD 
ResetTxD 
SetRTS 
ResetRTS 
SetDTR 
ResetDTR 
GetCTS 
DetDCD 
GetDSR 

GetRI 
GetHandle 
CheckInputs 
BaudRateSet 
ParitySet 
BitPerByteSet 
StopBitsSet 
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DLL is an option for the it to keep 
an eye on the serial port and send 
a Windows message when its sta- 
tus changes. With this it becomes 
unnecessary to poll the serial port 
at regular intervals. It is only when 
there is a change in status that the 
program is interrupted, similar to 
the way in which Windows informs 
a program that a key has been 
pressed. Some of you may have dif- 
ficulty in using this routine, but 
there is no need to panic. You don’t 
have to use this routine to operate 
the serial port; it has only been 
included as an extra for the more 
advanced programmer. 


The functions 


The functions and routines of the 
DLL are listed in Table 1. All rele- 
vant functions have been named to 
make their purpose clear. We will 
therefore not go into detail for all 
functions. For this you should look at 
the accompanying example, which 
can be downloaded together with 
the DLL from our website at 
www.elektor-electronics.co.uk with 
the number 020388-11. 

Before a port can be used, it has 
to be opened. This is done by the 
OpencoOM function. This function 
requires the port number of the ser- 
ial port that has to be opened. A 1 
corresponds to COM1, a 2 is for 
COM2, etc. When the port has been 
opened successfully, the function 
returns the port number; when there 
has been a problem this value will 
be zero. 

After use, for example when the 
program is terminated, the port has 
to be closed again. This is done by 
the CloseCOM routine. In between 
these events, characters can be 
transmitted using the SendCharCOM 
routine and received using Read- 
CharCoM. 

The status of the inputs (DCD, 
DST, CTS and RI) can be obtained 
using the functions GetDCD, etc. The 
DTR output is controlled via the 
SetDTR and ResetDTR functions. 
Similar functions are provided for the 
two other outputs, TxD and RTS. 

When the TxD output is driven 
directly you may run into problems. 
This output is normally used to 
transmit serial data. It’s true that 
this output can be controlled directly, 
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Figure |. Implementation of the CheckInputs function. 


but if you attempt to transmit a char- 
acter after the output has been set 
high with the Set TxD function, the 
transmission will fail and the pro- 
gram could crash. It is sufficient to 
reset the line using ResetTxD after 
which you can transmit as many 
characters as you like. 

The above functions don’t require 
much of an explanation. The oppo- 
site is true of the CheckInputs 
function. In order to use this function 
successfully you will first have to 
learn a bit about Windows mes- 
sages. But don’t let this put you off 
from using this DLL. The following 
section is only important if you want 
to make use of the facility to get a 
signal from Windows when the sta- 
tus of the serial port changes. 


Windows messages 


Programs can give commands to the 
operating system via its API, and in 
many cases Windows will issue a 
reply in one form or other. But this 
isn’t the only way in which applica- 
tions can communicate with Win- 
dows. 

The messaging system is another 
important means of communication. 
Virtually every Windows program 
uses this. The operating system uses 
these ‘Windows Messages’ to let an 
application know when a mouse but- 
ton has been pressed or if the pro- 
gram should be minimised, to give a 
few examples. 

A message consists of no more 


than three variables that have to be inter- 
preted by the application and subsequently 
acted on. The first variable specifies the type 
of message. The other two variables are used 
to pass on any other information that may be 
required. There wouldn't be much point if 
Windows told an application that the mouse 
pointer had moved, without telling it what 
the new position was. 

There are numerous message types 
reserved by Windows, but it is also possible 
for a program to send a message to another 
application. For this Windows has reserved 
messages with a type value greater than 
5000. These are the so-called User Defined 
messages and are therefore not sent by Win- 
dows, but can be can be used by applications 
for communicating between themselves. 
Most programming environments (such as 
Delphi, Visual C+ +, etc.) take care of these 
communications without requiring program- 
mer involvement. But most programming 
environments also offer the programmer the 
facility to deal with these messages them- 
selves when required. 

With Delphi it is possible to use the 
Application.OnMessage event to 
process the incoming Windows messages. 
The corresponding routine in Visual C+ + is 
Application: :OnMessage. This commu- 
nication mechanism is used by our DLL to 
inform the application whenever the serial 
port status changes. To send a message we 
can use the PostMessage function from the 
Windows API. 

The Windows API also has a function that 
waits until there is a change in status of the 
serial port. This function is called WaitCom- 
mEvent and is suitable for our application, 
but has the problem that it halts the execu- 
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tion of the program until such time that there 
is a status change of the serial port. This is 
obviously not our intention. This problem can 
easily solved through the use of so-called 
threads. 


Threads 


An application can run parts of the program 
in a separate thread. This means that there 
are effectively two programs active at the 
same time. One is the main program and the 
other is the thread. If this thread is halted it 
won't affect the operation of the main pro- 
gram. 

Figure 1 shows how the CheckInputs 
function is implemented in the DLL. The pro- 
gram calls this function, at which point the 
DLL creates a thread that is automatically 
started. From this point on the main pro- 
gramming continues to run normally, inde- 
pendently from the thread. The thread calls 
the Windows function WaitCommEvent, 
which causes Windows to halt the execution 
of the thread until there is a change in the 
status of the serial port. 
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Since Windows regards the 
thread as a separate program, the 
execution of our main program con- 
tinues normally. In this case the pro- 
gram is running the CheckInputs 
routine, which is part of the DLL. 
The DLL completes that routine and 
the main program can continue with 
its tasks unhindered. As soon as the 
status of the serial port changes, 
Windows will re-start the thread and 
states in a variable which event 
occurred in the serial port. The 
thread subsequently passes this 
information on to our program via a 
Windows message. 

When the program receives a 
Windows message it calls the func- 
tion AppMessage. This function 
checks if the message indicates that 
the status of the serial port has 
changed (in this case we've used the 
value 5100, but this may be any 
other value as long as it hasn't 
already been used by Windows). If 
this is the case then a routine is 


called that deals with the status 
change. In all other cases the mes- 
sage has to be dealt with by the 
actual Message Loop. 


And finally 


We can imagine that a few question 
marks remain after reading the pre- 
vious section. We therefore recom- 
mend that you have a look at the 
source code of the accompanying 
example program. Usually the quick- 
est way of learning about program- 
ming is to examine and adapt a 
ready-made program. We've used 
Delphi for the example program 
because this language is very easy 
to follow. The source code could eas- 
ily be converted into C++, for exam- 
ple. Elsewhere in this issue you'll 
find a simple COM Port Tester, which 
can be used to check the operation 
of your own programming efforts. 
(020388-1) 
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